Mobile data transmission and data services are constantly making progress. With the increasing usage of mobile communication, network organization and optimization is becoming more and more important. Also, in such context, security of handovers is being investigated, e.g. in the framework of LTE™ or LTE™-A and e.g. the EPS system and interfaces thereof, such as the so-called S1 interface between a network mobility entity e.g. also known as a mobility management entity, MME, and an access node providing (wireless) network access to a terminal such as a user equipment UE, the access node being e.g. also known as evolved NodeB, eNB.
Insofar, the present invention relates in particular but without limitation to mobile communications, for example to environments under LTE™ (Long Term Evolution) or LTE™-A (LTE™ Advanced), or any other communication scenario, potentially standardized by 3GPP (3rd Generation Partnership Project), ETSI (European Telecommunication Standards Institute) and/or other local or regional standardization bodies e.g. NGMN (Next Generation Mobile Networks), and can advantageously be implemented as or in chipsets, or modules, or units, or apparatuses of devices (e.g. network entities such as a transceiver device also known as base station, or NodeB, or evolved NodeB eNB, or e.g. a mobility management entity MME) forming part of those networks, as well as related terminal devices such as a so-called user equipment UE (e.g. smart-phones, a network-access enabled computers or laptops, or the like).
More particularly, as a specific example referred to in order to describe aspects of the present invention, the present invention relates to those apparatuses/units of devices or network entities that are applied in such communication networks or a part thereof, e.g. known as evolved packet system, EPS, network. Thus, security of handovers HO in such EPS network and security of handovers taking place with involvement of particular interfaces in such system, such as the so-called S1 interface between a MME and a eNB, are being considered.
With the evolution of LTE™ and/or EPS system, such cellular networks will become more and more complex, various and huge. For network operators, along with the uses of new technologies, to maintain security and/or data integrity is a big challenge.
The present invention relates to the security of handovers in LTE, and more specifically to failures of so-called S1 handovers, i.e. handovers, in which not only the eNBs, but also the MME are involved. Security of handovers is for example specified in 3GPP TS 33.401, more specifically in clause 7.2.8. thereof.
FIG. 1 illustrates some typical scenario for explanatory purposes. A network mobility entity referred to as mobility management entity MME is denoted by numeral 1. The MME has an interface/connection to other entities of the EPS (not shown in FIG. 1). Further, the MME has an interface known as S1 interface (S1-I/F) towards each of a plurality of access nodes referred to as evolved NodeBs, eNBs. Such access node eNB provides network access based on e.g. a wireless access technology for one or more terminals referred to as user equipments UE and denoted by numeral 4 and 4′, respectively. A source eNB denoted by numeral 2 is labeled as eNB #A. A target eNB denoted by numeral 3 is labeled as eNB #B. The expression source and target pertains to an assumed mobility of a terminal UE (4, 4′). Namely, with a moving UE, a UE is at a time t1 served by eNB #A, but after a handover HO served by a eNB #B. An interface between eNBs is referred to a X2 interface, X2 I/F. An interface between an eNB, 2 and 3, respectively, and a terminal UE, 4 or 4′, is referred to as Uu interface. In case of a handover between eNBs having an interface X2 there between, the HO typically takes place via the X2 interface. In case of a HO between eNBs without an X2 interface there between, the HO involves the S1 interface. In case of a HO via S1 interface, the MME derives, inter alia, parameters and/or keys such as {NH, NCC} and informs at least the NCC thereof to the target eNB which forwards it to the UE handed over in a handover command that is sent from the target eNB to the UE via the source eNB. Thus, NCC is forwarded to UE in a handover command that is sent from the target eNB to the UE via the source eNB, i.e. target eNB does not directly send NCC to UE over Uu.
In order to establish security in such EPS system architecture, various keys are established and/or derived in a hierarchical manner. E.g. a key K as a master or base key is stored permanently in an authentication centre AuC and universal subscriber identity module USIM. Using that key and various procedures such as one known as AKA (Authentication and Key Agreement) plural other keys in the hierarchical EPS system are generated and/or derived. Keys used at a specific entity or at a level of similar entities are also referred to herein as local level keys, whereas keys used to derive those may be referred to as higher level keys (determined/kept at hierarchically higher entities or nodes).
A key K_eNB, for example, is a eNB base key and set up/derived as intermediate key in a MME and UE based on other keys, e.g. upon a state transition of a terminal and/or by the UE and a target eNB upon handover of the terminal.
Particular focus in relation to the present invention will have to be put on keys referred to as “next hop”, NH, and “next hop chaining counter”, NCC, as will be explained below.
The use of Next Hop Chaining Counter (NCC) and Next Hop parameter (NH) is specified in TS 33.401, clause 7.2.8. Both the UE and the MME can derive NH from the current K_ASME, which was formerly generated and kept by MME and UE, and K_eNB in an iterative fashion according to TS 33.401, Annex A.4, when they know the K_ASME, K_eNB and the number of iterations, cf. TS 33.401, clause 7.2.2.
The NCC consists of the three least significant bits of the number of iterations performed in computing NH. Only NCC is transmitted to the UE in a handover for efficiency reasons. The UE can correctly derive a new NH from the currently stored {NH, NCC} pair and a newly received NCC only if that newly received NCC relates to an NH that was computed in the MME by at most seven iterations from the NH equal to the one stored in the UE. (This is a simple consequence of the fact that NCC has only three bits.)
In an S1 handover, the MME computes a new NH parameter, thereby increasing NCC by 1—with the exception marked with (**) below— and sends the {NH, NCC} pair to the target eNB. After a successful S1 handover, both UE and MME will have the same {NH, NCC} pair stored. When the S1 handover fails the MME will have increased NCC by 1 while the NCC in the UE will remain the same.
(**) Exception: The first NH sent to an eNB after the K_eNB was established corresponds to NCC=2, according to the rules in TS 33.401, clause 7.2.8.
In an X2 handover (including the Path Switch procedure), the MME computes a new NH parameter, thereby increasing NCC by 1—but see exception (**) above—, and sends the {NH, NCC} pair to the target eNB, in the Path Switch Acknowledge message, i.e. only after the handover had been successfully completed between UE, source eNB and target eNB.
So, an unsuccessful X2 handover has no effect on the NCC value in UE and MME. The new {NH, NCC} pair created in a successful X2 handover will be used only in the next vertical X2 handover, hence the UE will not learn about this new NCC value until then. While the effect of a successful X2 handover (including the Path Switch procedure) on the NCC value in the MME is straightforward the effect on the NCC value in the UE is a bit tricky to determine and depends on the history of handovers as follows:
If the current X2 handover is the first successful (S1 or X2) handover after the K_eNB was established then NCC does not change in the UE; the difference between the NCC values in UE and MME after the current X2 handover increases by 1 (if there was a preceding failed S1 HO) or 2 otherwise, cf. (**) above).
If the preceding successful handover was an S1 handover then NCC does not change in the UE; the difference between the NCC values in UE and MME after the current X2 handover increases by 1;
If the preceding successful handover was an X2 handover then NCC in the UE is set to the value of the NCC sent by the MME in that preceding handover; the amount by which the NCC value increases in the UE depends on the history even before that preceding handover; but the difference between the NCC values in UE and MME after the current X2 handover is more amenable to computation: it is equal to the number of failed S1 handovers between the current and the preceding X2 handovers plus 1.
It was observed in laboratory tests by applicant that S1 handover failures may lead to loss of synchronization of so-called NextHop (NH) parameter between UE and MME and consequently to a connection failure. Namely, applicant observed in laboratory tests that S1 handover requests could be rejected several times, while the UE remained connected to the same source eNB. Those tests involved a low mobility case, in a scenario where a laptop was being moved from one corner of a building to another one. This move caused an S1 handover attempt, which failed due to the target eNB being congested. By this, the NCC value was increased by 1 in the MME while it remained the same in the UE, because the new NCC value could not propagate from the MME via the new target eNB towards the UE due to the handover failure, or, stated in other words, because the new NCC will only be propagated to UE if the handover actually happens.
The radio conditions permitted the UE to remain connected to the source eNB. As the laptop did not move any further the radio conditions did not change any further, and, after some time, another S1 handover attempt was made, failing again (and increasing the NCC value in the MME again), while the UE still remained connected to the source eNB. When finally a successful (S1 or X2) handover was made this then led to a condition (according to the ‘background’ information above) where a UE and an MME would compute different NH parameters and, hence, the UE and the eNB would compute different AS level cryptographic keys, leading to a connection failure.
The observed scenario is plausible enough, and the negative impact sufficiently important, to warrant implementing countermeasures.
Generally, prior art can be found in 3GPP TS 33.401 and the related stage 3 specifications 3GPP TS 24.301 and 3GPP TS 36.331. An NCC length of three bits has so far been considered sufficient to prevent any loss of synchronization due to handover failures.
To the inventors' knowledge, the failure case observed in applicant's laboratory tests described above has not been publicly discussed yet. Hence, as the problem had not been revealed, no countermeasures have been proposed so far.
Generally, as a countermeasure it is conceivable to use a K_eNB re-keying as specified in 3GPP TS 33.401, clause 7.2.9.2. This could be used to re-synchronize the NH parameter in MME and UE. The big disadvantage of this re-keying procedure is that it requires a run of the EPS AKA authentication protocol. This, however, is undesirable as operators are currently looking for ways to reduce the load on the home subscriber server, HSS, caused by authentications, which is considered too high already.
Thus, there is still a need to further improve such systems.